Summary
Stateless services do not depend on local instance memory between requests. Stateful services maintain local session, data, or coordination state.
Interview Points
- Stateless services are easier to scale, load balance, and replace.
- Stateful services may be necessary for databases, caches, streams, sessions, or coordination.
- Externalize state to durable stores where possible.
- Stateful systems need replication, failover, and recovery planning.
- Sticky sessions are a tradeoff, not a default.
2-3 Minute Interview Script
“A stateless service can handle any request on any healthy instance because it does not rely on local memory from previous requests. That makes scaling and failover much easier.
A stateful service holds important local state, like a database, cache, stream processor, or session server. These systems can be necessary, but they require careful replication, backup, failover, and consistency design.
In web architecture, I try to keep application servers stateless and put state in databases, caches, or tokens where appropriate. That lets load balancers route freely and lets instances restart without user impact.
Interview line: stateless is easier operationally; stateful is sometimes unavoidable and must be designed deliberately.”
Follow-Ups
- Are JWT-based sessions always better?
- When do sticky sessions make sense?